技術的負債への向き合い PHP編｜10年越えプロダクトを提供する3社が語ります！
https://gyazo.com/0ff0e4a5a5a899c8d4dee41990737d57
現場のいちメンバーの視点からの技術的負債の向き合い方 プロダクト開発部 エンジニア 福井将之
日々取り組んでいる対応
require_onceの見直し
依存しているライブラリをアップグレードする
厳密な型付け
現場で向き合うための手持ちの道具
自分のプロダクトとして振る舞う
学びを得られる感謝と驚き
技術的負債は動くことで価値を産み続けているもの
感謝と尊敬をもつ
何もしないならただ乗り
自分のものにするために見る
自分の記憶にどう定着させるか
批判的に見る
ラフに見る
丁寧に見る（深掘り）
図にまとめる
障害対応の発生から完了までを経験
アラートは全て見てみる
自分から手を挙げる
理解のための徳等席
集中モード
問い合わせ対応を率先して対応する
障害対応と似ている
向き合うモチベーションはどこにある？
仕事として
新しい視野を得られる
自分のため、人のため
BASE Department Product Division EPM 宮村 幸宏 モノリスをモジュラーモノリスにするコードベースの書き換え
注文管理モジュールに切り出す
どのように設計を進めるか
現状のコードの理解
難しい
地道にやっていく
社内のナレッジベースをみる
先入観を捨ててコードの違和感に向き合う
未知の謎を見つけたら祝う
理想のコード検討
業務整理
集約の定義
ルールや負荷情報の書き出し
ライフサイクル
ワークフローの分解でオブジェクト群に操作
あらゆる知識を吸収する
使用
運用
業務
現実的に書くべきコードの判断
モジュールの境界をどう定めるのか
一部を非同期化するなど
元のコードを消すためには完全理解しておく必要がある
寿命が長くあるためにそこそこ理想的に書かないと意味がない
プロダクト開発ユニット SREグループ 山下 祐
アカウント設定画面の刷新
既存の開発資産を最大限に再利用していく
既存システムの構造と課題
独自フレームワーク
ミドルウェアの仕組みがない
機能依存のクラスが存在するライブラリ
Web APIが必要
モダンフレームワークに近い体験を求める
技術的制約と解決アプローチ
フレームワークを完全に乗り換える選択はできない
拡張していく
軽量ルーティングライブラリを載せていく
リファクタリングを後回しにする戦略
ポート＆アダプター
入口と出口を用意する
外側は既存ライブラリへの依存
内側は依存しない形で自由な実装ができるようになった
クロストーク
kubell
8.0
BASE
7.0, 8.0系
コドモン
8.1系
リアーキテクチャのプロジェクトはどれくらい長いのか大きくなるのか
kubell
担当したところは小さかった
大きいモノレポなのでリポジトリを分けるなどしていくなどしていく
BASE
順番に新しくなったものを切り替えていく
コドモン
APIベースで切り替えている
コドモン
ユニットテストを書く
BASE
負債を借りるのが早いので嫌になったら返すプロセスをつくる
kubell
自動テスト
コドモン
許可は求めたことはない
気づいたタイミングでやっている
負債を入れ込んだ見積もりをしている
BASE
技術検証など
kubell
しっかりと必要性を伝えて一緒に考える
ROIはどう測る？
kubell
変わったCI/CDの時間は説明として出しやすい
コドモン
正面からは戦わない
小さく初めて小さく失敗するを繰り返す
言語やフレームワークのアップデート時期はどこで行うか
BASE
基盤チームが主で行っている
kubell
コドモン
各チーム持ち回りでやる
生成AIは活用しているか？
kubell
BASE
コドモン
レビュー機能
リアーキテクチャの楽しさ・やりがい
kubell
ぼくのかんがえたさいきょうのせっけいができると嬉しい
BASE
機能を極力変えず、質を落とさない
技術的なところに専念できるところが楽しい
コドモン
撤退戦のときに動き続けるシステムを運用するのが好き kubell
CIは5分前後
並列テストでそれくらいになるように
デプロイは10分程度
BASE
新しい環境
CIは10分かからない程度
CDは30分くらい
古い環境
CIは10分ちょい
CDは1時間くらい（確認含めて）
コドモン
CIは7~8分
デプロイは10分
技術的負債への向き合い方から明日からあなたにもできる！工夫を１つ教えてください
kubell
コドモン
チェッカーを作れるといい
プロダクトに影響ないもの
BASE
これまで動いてきたものに敬意を払う
それに対して思いを馳せる